home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 231 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.9 KB  |  91 lines

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: austern@isolde.mti.sgi.com (Matt Austern)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Explicit constructor call vs Temporaries
  5. Date: 1 Feb 1996 22:54:42 GMT
  6. Organization: SGI
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <AUSTERN.96Feb1104027@isolde.mti.sgi.com>
  9. References: <4e6plv$idn@eclipse.eng.sc.rolm.com> <4eq5p2$fpu@fsuj01.rz.uni-jena.de>
  10. Reply-To: austern@cardboard.mti.sgi.com
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. Content-Type: text
  13. X-Nntp-Posting-Host: isolde.mti.sgi.com
  14. In-Reply-To: mkt@isun04.inf.uni-jena.de's message of 01 Feb 1996 09:54:08 PST
  15. Content-Length: 2096
  16. X-Lines: 67
  17. Originator: clamage@taumet
  18.  
  19. In article <4eq5p2$fpu@fsuj01.rz.uni-jena.de> mkt@isun04.inf.uni-jena.de (Tilo Koerbs) writes:
  20.  
  21. >  About the error message in this posted code:
  22. > > class T {
  23. > >   T();
  24. > >   ~T();
  25. > > }
  26. > > 
  27. > > class X {
  28. > >   X();
  29. > >   ~X();
  30. > >   f(T& t);
  31. > > }
  32. > > 
  33. > > int main() {
  34. > >   X x;
  35. > >   x.f(T());  // Compiler complained on this line
  36. > > }
  37. > The 'temporary' (it is an UNNAMED) T()-object is NOT const!
  38. > Consider:
  39. >     class T {
  40. >     public:
  41. >         T();
  42. >         ~T();
  43. >         void nonConstFct() {}
  44. >     };
  45. >     int main() {
  46. >         T().nonConstFct();  // Allowed!!!
  47. >     }
  48. > And so the compiler should have no problem with this code!
  49. > I compiled it without any problem!
  50.  
  51. It's true that T().nonConstFct() is legal.  It's also true that 
  52. x.f(T()) is illegal.  Those two cases are very different!
  53.  
  54. The issue isn't whether what T() returns is const, but whether it's an
  55. lvalue.  This is a crucial point, since a non-const reference may not
  56. be bound to an rvalue.  Unfortunately, you have to read section 8.5.3
  57. [dcl.init.ref] a little bit carefully to see this; it's quite
  58. unambiguous, though.  Paragraph 8 begins "--Otherwise [i.e. if a
  59. reference is being initialized with an rvalue], the reference shall be
  60. to a non-volatile const type (i.e., cv1 shall be const)."
  61.  
  62. (As usual, the complicated language in 8.5.3 simply formalizes what
  63. you'd expect anyway.  Creating a reference to a temporary is a
  64. problematic operation, so it's forbidden except in certain restricted
  65. cases.)
  66.  
  67. And, indeed, the explicit invocation of a constructor yields an
  68. rvalue.  The draft standard says this in several places, and implies
  69. it in others.  One such place is section 3.10 [basic.lval], paragraph
  70. 5: "Constructor invocations and calls to functions that do not return
  71. references are always rvalues."  See also the footnote to paragraph 2:
  72. "Expressions such as invocations of constructors and of functions that
  73. return a class type refer to objects, and the implementation can
  74. invoke a member function upon such objects, but the expressions are
  75. not lvalues."
  76.  
  77.  
  78. -- 
  79. Matt Austern
  80. SGI: MTI Compilers Group
  81. austern@isolde.mti.sgi.com
  82.  
  83. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  84.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  85.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  86. ]
  87.